Notes for 12/2/08

· Summary of Issues

· Clarification of points

o Legacy Software:

§ Access?

· Yes. To relevant ones.

§ Things that you would like to see transferred over

· No. Take it as lessons learned.

§ Export to the legacy formats

· New point of entry, just need to export to XML/SQL. Engineers can map the spokes

§ Able to translate from legacy? Yes, that would be ideal.

§ All new products created through our application. Phasing out legacy systems.

o Questions asked and answered:

§ Can you give us a few examples of products from your current catalogs?

· Any PAETEC services, equipment rental, backup, T1s. All inclusive (like Time Warner for businesses) hosting, anything we sell, toll free number, sold software.

§ Are we able access to your Oracle database? How can we do so?

· No access to any live data.

· We will get sample data for testing info.

· No strict requirement for method of SQL output.

§ Could you give some examples of what a service, feature, attributes, etc. might be?

· More services than hardware

· Service and product are kind of synonyms. Service can mean dial tone, or an instance of a product. Service = Product.

· Service ordering digital cable

· Feature non standard or HD channels

· Attributes: which channels. Configuring blocked numbers

· MRC Monthly recurring charge

· NRC non-recurring charge

· Usage pricing is like based on use, ( 2 cents per minute)

· MRC and NRC apply to pricing and cost.

§ When exporting data to an external format, should the entire catalog of products be exported? Is it necessary to support exporting groups of products or single products?

· One at a time is the highest priority

§ When you say each entity should have its own ID are you saying that it’s unique in the product catalog and should/could be contained in multiple products?

· Spoke systems work off unique id. Doesn’t mean it has to be central, but it needs to be assigned, not the same across systems.

o Versioning

§ Versions of catalog, customers have different versions of the products at any given time. See differences; see changes like between 1.0 and 1.2.

§ Talk about this more detailed in future meetings.

o When we get license for blueprint it must be forwarded to non-RIT email, change to xml file when downloaded.

o Everything is a strict hierarchy. Actual entities are unique, but a template would be good. There is not a good way to share features with services, etc.

o Synopses: we can put up a product charter, expectations from RIT and PAETEC. Basic outline and expectancies.

o Blueprint:

§ They did get the license. They are monthly and will be resent licenses.

§ Call email support, but don’t want to spend a lot of time so filter trough the details.

§ Use cases, tie prototypes to them, cool features. Generate test cases off use cases.

· Decisions

o Other Two Metrics will be: lines of code, requirements met, use cases satisfied, or something along those lines.

o Come out to PAETEC next Tuesday at 4pm. Erika will send out an email with direction.

o The user can interact as either a web-app or stand-alone. Design part of it without a decision. Flush out both options. People using have access to network. Stand-alone makes deployment much more complex. Many of PAETEC’s current tools are web-apps.

o Set up Primary contact person. To minimize the email.

· Action Items (w/ person responsible and dues dates)

o Research Telecom

o Sign NDA

§ Assigned to Erika

§ Due 12/9

o Blueprint License

§ Assigned to Nathan

§ Due ASAP (completed)

o Project Synopses

§ Assigned to Phil

§ Due 12/5